Fix #201: re-fold the HRV baseline on a window switch instead of restarting calibration - #207

Follow-up to #195 / implements #201.

Problem

Switching the HRV window (Whole-night ↔ Deep-sleep) in Settings re-anchored the HRV baseline epoch to now. That drops all history and restarts the ≥4-night calibration, so a user with plenty of nights fell back to "calibrating" for several nights and Charge went nilScore. That reads as "the deep-sleep setting is broken" (#195).

Why the reset is unnecessary

The same handler already forces a re-score, and analyzeRecent:

1. recomputes the recent ~21 nights' avgHrv under the new window, deterministically from stored R-R, and
2. re-folds the HRV baseline from those same nights in the same pass (baselines2).

The HRV baseline is a 14-night-half-life EWMA (Baselines.metricCfg["hrv"]), so it's dominated by that fresh, just-re-scored tail. A plain re-score therefore already lands the baseline on the new window for anyone with ≥ minNightsSeed valid nights — no artificial calibration reset needed.

Change

• Drop the hrvBaselineEpoch = now write from both window-switch handlers (Strand/Screens/SettingsView.swift, android/.../ui/SettingsScreen.kt); keep the forced re-score (Android also keeps the analyzeWatermark clear so the re-score runs even though the raw HR fingerprint is unchanged).
• Update the picker subtitle + the Android toast to say the switch takes effect right away once you have a few nights of data.
• The manual "Recalibrate Charge baseline" button is untouched — it still resets both epochs on purpose.

Parity & scope

• Both platforms changed together (parity contract).
• A genuine cold-start user (< minNightsSeed valid nights) still calibrates honestly — expected, per the issue.
• Known nuance for the reviewer: a user with many imported whole-night nights but very few computed nights could still see a brief skew (the imported tail isn't re-windowed) — but they'd be calibrating anyway with < 4 computed nights. Not addressed here on purpose.

Verification

• swift test — StrandAnalytics BaselinesTests 22/22 green, including the new testWindowSwitchRefoldStaysUsableWithoutEpochReset.
• Strand macOS app target compiles (app-build.yml is disabled, so app-target Swift has no default CI).
• Added an Android parity test (HrvBaselineRecalibrationTest.windowSwitchRefold_staysUsableWithoutEpochReset) mirroring the Swift one; not run locally (no Android SDK) — relying on android.yml.
• Still needs on-device confirmation across several nights, per the issue: switch the window with ≥4 nights of history and confirm Charge stays scored (does not drop to calibrating) and the HRV trend reflects the new window.

🤖 Generated with Claude Code